-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add npm update step to release process #155
Conversation
@@ -29,7 +29,8 @@ The `develop` branch is the development branch which means it contains the next | |||
## Release instructions | |||
|
|||
1. Branch: Starting from `develop`, cut a release branch named `release/X.Y.Z` for your changes. | |||
1. Version bump: Bump the version number in `insert-special-characters.php`, `readme.txt`, `package-lock.json`, and `package.json` if it does not already reflect the version being released. | |||
1. Version bump: Bump the version number in `insert-special-characters.php`, `readme.txt`, and `package.json` if it does not already reflect the version being released. | |||
1. Update packages: Run `npm update` so that `package-lock.json` gets updated from the version bump in `package.json` in the previous step as well as handle various available dependency updates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this but any concerns here with introducing bugs from an updated dependency?
We normally lock our dependencies to minor releases (using the ^
syntax) and hopefully there aren't any breaking changes in a minor but there's a possibility here that we run npm update
, it updates something that introduces a bug/regression/incompatible change.
Maybe we just add additional instructions to this step around doing some quick testing to ensure things still work? This will vary based on the plugin, basically you'd need to look at what dependencies
and devDependencies
we are loading and what those are used for and then test appropriately. Could just be tests around ensuring the plugin builds properly, could be more functional type tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this will likely vary by plugin, but hopefully a combination of decent e2e tests and a manual check during the Test
portion of the release process will catch any issue? Alternatively we could go back to Dependabot opening PRs for every minor bump in dependencies, but that felt overly chatty. Not really certain that I'm opinionated on best approach here besides wanting to keep things updated (but obviously still working in the plugin) with the least amount of mental gymnastics needed by a maintainer to stay on top of these changes.
Description of the Change
This follows from the change in #154 to adjust where we bump dependencies from a Dependabot automated check to during the release process.
Alternate Designs
Keep as-is prior to #154 and allow Dependabot to bump dependencies.
Possible Drawbacks
no significant drawbacks identified.
Verification Process
Use markdown previewer to preview copy changes in release process.
Checklist:
Changelog Entry
Credits
Props @jeffpaul.